home *** CD-ROM | disk | FTP | other *** search
/ Power Tools 1993 November - Disc 2 / Power Tools Plus (Disc 2 of 2)(November 1993)(HP).iso / hotlines / cpethl / deccase / b04e003t.txt < prev    next >
Text File  |  1992-08-06  |  9KB  |  182 lines
  1. 6-25 CASE SHOULD PLAY A KEY ROLE
  2.  
  3. Newness has a universal appeal.  For most software developers, for
  4. instance, the greatest excitement and satisfaction comes from designing
  5. new systems.
  6.  
  7. It comes as no surprise, then, that the early emphasis in the field of
  8. computer-aided software engineering (CASE) has been on tools for
  9. developing new software.
  10.  
  11. The first CASE tools to capture public attention in the mid-1980s were
  12. most readily applied to building new applications, since they addressed
  13. front-end analysis and design.  However, both the definition and market
  14. for CASE have evolved from this original point to include methods,
  15. procedures and tools that cover the entire software lifecycle,
  16. including the implementation and maintenance phases.
  17.  
  18. This evolution is critical, for if CASE is to have the transformational
  19. impact many predict, it must meet the needs of the 80 percent of all
  20. software professionals working on existing systems, not just the 20
  21. percent developing new ones.
  22.  
  23. THE MAINTENANCE MORASS
  24.  
  25. In many IS shops, the biggest factor contributing to applications
  26. backlogs is not requests for new programs, but the need to maintain
  27. existing ones.  Applications written in unstructured COBOL--many of
  28. them 15 to 20 years old--have undergone so many fixes and alterations
  29. that their logic may be nearly impossible for programmers to figure
  30. out.
  31.  
  32. It is estimated that there are more than 100 billion lines of
  33. production 3GL code, most of it in COBOL.  Gartner Group estimates the
  34. average age of applications now in production to be 12 years--which
  35. means they completed their development in the late 1970s and benefited
  36. only from the technology available then.
  37.  
  38. Few of these applications will ever be rewritten, because companies
  39. can't afford to take them down for the time required to rewrite them.
  40. On the other hand, most companies don't have the personnel to develop a
  41. new program while concurrently maintaining the old one--so the new
  42. development is put off.
  43.  
  44. Thoughout the corporate world, old systems are continually modified and
  45. revised, making them larger and more complex.  Consequently, people,
  46. products and processes become attached to them and an infrastructure is
  47. created that has a vested interest in perpetuating the system.
  48.  
  49. Eventually, replacing the system becomes a bigger problem than
  50. operating it due to the massive organizational disruption such a change
  51. would cause.  So the inertia becomes greater, and still more
  52. modifications are made to the system as it is called upon to do things
  53. never intended when it was originally designed and built.
  54.  
  55. The only way to break this cycle is to apply CASE or associated
  56. technologies to maintaining existing code.   Many experts believe that
  57. software maintenance is part of CASE--that, in fact, CASE will not be
  58. widely accepted for the creation of new systems until it can also
  59. address the existing code maintenance problem.
  60.  
  61. The problem is not limited to the production environment.  In the
  62. technical software development market, maintenance currently eats up 30
  63. to 40 percent of research and development time, slowing time-to-market
  64. for new software technology and adding considerable cost to the
  65. process.
  66.  
  67. Factors that contribute to the maintenance problem in both the
  68. development and production environments include:
  69.  
  70. .  missing systems-level documentation;
  71. .  missing connections between pieces of applications;
  72. .  missing or sloppy application and database design;
  73. .  obsolete user documentation;
  74. .  disorganized libraries and directories; and
  75. .  fear of upsetting a temperamental system.
  76.  
  77. RE-ENGINEERING AS A SOLUTION
  78.  
  79. Most if not all of these problems can be addressed by software re-
  80. engineering (SRE), the products and strategies focused on leveraging
  81. existing program assets.  SRE often is thought of interchangeably with
  82. "maintenance," but the two are not synonymous; indeed, effective
  83. maintenance is the key component of SRE.
  84.  
  85. The difference between maintenance and re-engineering is one of scope.
  86. Maintenance is functional in nature, and is more time-critical: An
  87. application must be modified immediately because it is "broken."
  88.  
  89. Re-engineering, on the other hand, means looking at the entire
  90. portfolio of existing applications and how they can be improved.
  91. Usually there is a luxury of time to really think out the purpose of
  92. the applications and the analysis of their relationship to the
  93. organization's overall strategy.  SRE requires a much broader
  94. perspective, and it usually is not tactical in nature.
  95.  
  96. Maintenance programming is difficult--and often unsuccessful--because a
  97. large part of it involves mental reverse-engineering: Maintenance
  98. programmers must find other people's ideas in code.
  99.  
  100. REVERSE ENGINEERING
  101.  
  102. Reverse engineering is a specific subset of SRE.  It is the process of
  103. extrapolating from code a system's original specification.
  104.  
  105. Reverse engineering is a complex task that involves the data,
  106. programming logic, system calls and documentation.  A developer must
  107. work bottom-up, starting with the existing application and backing up
  108. through progressively higher levels of abstraction--the source code,
  109. the design, the dataflow diagrams, logical data models, entity
  110. relationship models, finally to the business model itself.
  111.  
  112. In fact, reverse engineering an application could well be a waste of
  113. time if the underlying business model has changed.  Under new business
  114. conditions, circumstances and premises, an old program may indeed be
  115. obsolete and not worth reverse engineering.
  116.  
  117. Given its bottom-up orientation, reverse engineering looks like it
  118. should be done in steps, which implies a lot of pre-processing before
  119. the desired result is obtained.  The tools that are available now only
  120. separate the problems from the source code and, at best, fix specific
  121. instances of problems.
  122.  
  123. There are some tools that provide navigation by structure chart
  124. graphics.  However, there are few true abstract program representation
  125. systems, and no one product does it all.
  126.  
  127. Research continues within the software industry to understand and
  128. eventually achieve automatic reverse engineering.  Rule-based systems
  129. employing artificial intelligence techniques offer a path to a
  130. solution.  Meanwhile, software vendors offer re-engineering services
  131. based on manual techniques to create the experience base required to
  132. arrive at the rules for an automatic system.
  133.  
  134. Tools available today provide sophisticated reports that, in effect,
  135. require programmers to become analysts--they have to know what to do
  136. with all the information provided in the reports.  This will become
  137. more evident when tools that actually produce the specification become
  138. available--understanding and analyzing the graphical representation
  139. will be key to effectiveness.  Training will certainly be essential to
  140. using these products.
  141.  
  142. REASONS FOR RESISTANCE
  143.  
  144. Even after full-fledged tools are available, there may be a long
  145. acceptance curve before they are widely used and successful.  Until the
  146. methodology is accepted, the tools will not be totally useful.  This
  147. means a change in daily habits, which some organizations never achieve.
  148.  
  149. Reverse engineering tools also are likely to create "culture shock" for
  150. many programmers.  As some have had difficulty adjusting to icon-based
  151. code generators, a similar reaction is likely from those who work with
  152. reverse engineering tools--for an experienced programmer, going
  153. directly back to the specification may be the equivalent of "iconic
  154. maintenance."
  155.  
  156. Another concern is that there may actually be a loss of productivity as
  157. the restructuring and reverse engineering tools destroy the landmarks
  158. in the the code that the maintenance programmer has come to rely on.
  159. It may make the system even more unmaintainable, which in turn may
  160. cause management to hesitate to use such tools.
  161.  
  162. Another management concern will be cost justification.  Cost savings
  163. cannot be measured at the time code is restructured or reversed; it has
  164. to be done over time as the application continues to be maintained.
  165. Therefore, the cost justification process is a slow one.
  166.  
  167. Overall, methodologies, guidelines, and just plain helpful hints are
  168. missing now for reverse engineering.
  169.  
  170. For all the potential problems, however, there are clear indications
  171. that the creation and use of sophisticated tools to aide re-engineering
  172. will make for better information systems, and will make life better for
  173. information systems professionals.
  174.  
  175. Digital Equipment Corp. is committed to providing the most effective
  176. and useful solutions for software re-engineering and reverse
  177. engineering, so its customers can create information systems that
  178. become the strategic resource--well managed, easily maintained--that
  179. business today has come to expect.
  180.  
  181.                                   ###
  182.